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SYSTEM AND METHOD FOR PROVIDING SOFTWARE PROPERTY ASSURANCE TO A HOST 

5 Cross-Ref erences to Related Applications 

This application claims the benefit of U.S. 
Provisional Application Nos. 60/047,247, filed May 21, 
1997 and 60/037,817, filed February 5, 1997. 
Background of the Invention 

10 The field of the present invention is software 

verification and trust, and in particular relates to 
providing assurance to a host that a piece of software 
possesses a particular property. 

The advent of distributed computing has increased the 

15 need for an efficient way to provide assurance to a host 
that a piece of software has a property. A piece of 
software is a set of instructions adapted to be executed 
by a processor on a host. An example of a processor is a 
general purpose microprocessor. Another example of a 

20 processor is an Application Specific Integrated Circuit 
(ASIC) . Yet another example of a processor is a Digital 
Signal Processor (DSP) . 

An example of a property of a piece of software is 
the identity of the author of the software. Another 

25 example of a property is the identity of the compiler used 
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to generate the piece of software. In certain 
applications, it is important to provide assurance to the 
host that a piece of software cannot alter the contents of 
a file stored on a disk drive of the computer on which the 
5 software is executed. This is another example of a 
property of a piece of software. 

In a distributed computing environment, software 
(e.g., applets, servlets, CGI bins, etc.) is obtained by 
a host from a provider. As used herein, a provider is a 

10 party that provides software that is adapted to be 
executed by a host. An example of a provider is a software 
manufacturer. Another example of a provider is a server 
on the World Wide Web connected to the Internet, where the 
server acts as a middleman, receiving software from a 

15 software manufacturer and sending software to hosts to be 
executed. 

A host is a party that executes software. An example 
of a host is a client with a browser that is adapted to 
execute Java byte code, the client being adapted to be 

20 connected to the World Wide Web through the Internet. For 
example, a client computer (a host) with a browser obtains 
a Java applet from a server (a provider) on the World Wide 
Web over the Internet. The client executes the software, 
hoping that the software will not have any malicious 

25 properties, either intended or accidental, such as 
infecting the client with a virus, improperly altering 
files stored on the client, or sending private information 
stored on the client to another computer connected to the 
Internet . 

30 Certain known systems provide the client with 

assurance that the software will not act improperly or 
maliciously, i.e., that the software has certain 
properties that preclude such behavior. However, these 
known systems are of limited usefulness, and can be 

35 expensive and inefficient to implement. 
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One known system for providing assurance relies upon 
the software provider to extensively test the software 
once the software is received from the software 
manufacturer. In one embodiment of this system, a provider 
5 tests the software under many possible conditions. If the 
software passes the tests, then the provider agrees to 
distribute the software to a host that trusts the 
provider. 

This known system of provider testing can be 
10 disadvantageously unreliable because most software cannot 
be tested under all possible conditions. It is therefor 
possible that software that passes all of the tests could 
prove to be harmful when it is used under untested 
conditions. Further, if the nature of the tests become 
15 known by an adverse party, malicious features purposely 
designed to circumvent the tests could be inserted into 
the software. This could prove devastating to the host. 

If the provider has access to the software 
manufacturer's source code, it can.be easier for the 
20 provider to test certain properties of the software 
statically (without executing the software) . But many 
software manufacturers are reluctant to release source 
code because it discloses valuable intellectual property 
(e.g., trade secrets) that is more valuable if kept 
25 confidential. 

One known system for providing assurance as to the 
properties of source code is implemented in the Java 
programming language. Java byte code contains the same 
information as Java source code. Byte code is portable 
30 compiled code that is ready to be interpreted on a 
platform using a Java interpreter. Java byte code is 
verified every time a Java applet is received and before 
it is executed. Software is said to be verified when it is 
analyzed and determined to possess a particular property. 
35 For example, a piece of software can be verified to 
possess the property of not writing data to any file 
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stored on a host. A "verifier" is a first piece of software 
adapted to be executed by a processor to verify a second 
piece of software. Known browsers, such as certain 
versions of the Netscape Navigator manufactured by the 
5 Netscape Communications company, include Java verifiers 
that verify Java byte code before it is executed. 

Java byte code can be verified statically. Byte code 
is verified statically when it is analyzed by examining 
the code itself, rather than analyzing its behavior when 
10 it is executed. Byte code that is verified by examining 
its behavior when it is executed is said to be dynamically 
verified. 

An example of property verified in Java byte code by 
a Java byte code verifier is that a piece of Java byte 

15 code contains no type errors. A static type- inference 
analysis is carried to ensure, for example, that a 
variable A of type char (character) is not used in the 
code in such a way as to produce a type error (e.g., type 
char variable A is not used in arithmetic expressions with 

20 floating point variables to yield an integer, i.e., a 
character string is not added to a real number to yield an 
integer) . If the Java code is approved by the verifier, 
then it provides a reasonable (as yet formally unproven) 
basis for the host to conclude the byte code possesses the 

25 property of not giving rise to type errors during 
execution. 

However, the verifier can be imperfect, and can 
indicate that a piece of Java byte code has a property 
when in fact it does not, at least under certain 
30 conditions. Also, analyzing Java byte code every time 
before it is executed to determine if it has a property 
disadvantageously imposes a significant burden on the 
host, especially for analyzing the byte code of large 
applets . 

35 Because it is imperfect, the Java verifier is 

continually under development. As used herein, a Verifier" 
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is a set of verification instructions adapted to be 
executed by a processor to determine if a piece of 
software (called a "set of subject instructions*, or 
"subject set") possesses a particular property. When a flaw 
5 is found in the verifier, the verifier must be revised and 
updated. Distributing the latest version of the Java 
verifier is logistically difficult, because the verifier 
resides at every local platform that executes Java code. 
For example, the verifier resides in millions of copies of 
10 the Netscape browser manufactured by the Netscape 
Communications company, and it is unlikely that every such 
browser executes the latest updated version of the Java 
verifier. Thus, outdated verifiers are widely used, 
providing a diminished level of security by operating with 
15 weaknesses that can be widely known and exploited. 

Another approach to providing assurance is provided 
by formal verification. Software that is formally verified 
is analyzed mathematically to prove that the software has 
a property. Formal verification is generally carried out 
20 by the host because the provider remains untrusted. Even 
if the host provides trusted formal verification software 
to the provider, there is no guarantee that the formal 
verification software will not be compromised in some way 
at the providers site, and thus improperly analyze 
25 harmful software without detecting its harmful aspects. 
Formal verification techniques" are also unwieldy, and can 
often be impractical to implement for software of any real 
complexity. 

The problem of dealing with an untrusted provider has 
30 been addressed in one known system by having the provider 
construct a proof establishing that a piece of software 
has a property, and shipping the proof along with the 
binary version of the software to the host. The binary 
program is annotated to enable the construction of a 
35 verification condition by the host. If the host can 
establish the verification condition, then the host is 
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assured that the software has the property. This 
advantageously reduces the burden on the host, which must 
only check the proof, which can be carried out much more 
quickly and easily than having to construct the proof. 
5 Although generally faster than proof construction, 

proof checking can still prove to be a substantial task, 
depending upon the size of the proof. In the case of 
highly mobile code, such as applets and agents, the proof 
must be checked for each execution, which can incur 
10 unacceptably high overhead for the host. Also, proof 
checkers are installed and executed on the host computer, 
and are thus subject to the same logistical problems 
(distribution and maintenance of updates) as for the Java 
verifier. Also, in order for proof checking to be 
15 effective, the full proof and any invariants that 
contribute to the proof have to be released by the 
provider to the host. The disclosure of invariants can 
actually reveal more valuable proprietary information than 
the disclosure of source code. Such a disclosure of 
20 invariants can disadvantageously compromise the 
confidentiality and therefore the value of certain of the 
software manufacturers intellectual property. 

Another method of providing assurance in an automated 
fashion is the ActiveX model. ActiveX is based upon the 
25 assumption that software built by well-known individuals 
or companies can be trusted.- The authenticity of the 
software is established by an attached cryptographic 
signature. If the key of the signature corresponds to a 
key in a trusted group, then the software is accepted and 
30 executed without requiring any further static or dynamic 
checks. Signature checking is very quick, and adds little 
overhead. 

However, the trust provided by the ActiveX system is 
based only upon establishing the identity of the 
35 manufacturer and not more. Relying entirely on the 
reputation of a manufacturer can be risky. Further, if the 
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cryptographic keys are stolen or misused, signed (and 
hence trusted) software could wreak havoc on a host. 
Likewise, if a trusted insider with a trusted key builds 
malicious software and signs it, the malicious software 

5 will be accepted and run without further checking, 
possibly with disastrous results. 

Under yet another known system, providers can have 
their software tested by a third party that is trusted by 
the host. The third party analyzes and then signs software 

10 if the analysis shows the software to possess a property. 
The process .of analyzing and then signing a piece of 
software if the analysis shows the software to possess a 
property is termed "certification". However, the provider 
must trust the third party to maintain the confidentiality 

15 of the testing process and of any intellectual property 
belonging to the manufacturer. This can make a 
manufacturer reluctant to use this known system. 

In summary, analyzing software properties locally (at 
the host) can be impractical (particularly in distributed 

20 systems) because an updated verifier has to be universally 
distributed every time a security weakness and/or flaw is 
discovered in the present version of the verifier. 
Formally verifying source code at the host can be 
impractical, burdensome, and involve the disclosure of 

25 intellectual property that the software manufacturer would 
prefer to keep confidential. Having a third party analyze 
the software and sign it reduces the burden placed on the 
host and can involve fewer logistical problems, but fails 
if the third party breaches its trust, or if cryptographic 

30 keys are mismanaged. 

Summary of the Inv ention 

According to one embodiment of the present invention, 
a system and method provide assurance to a host that a set 
35 of subject instructions adapted to be executed on a host 
processor possess a property. 
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In one embodiment, a verification processor executes 
a version of a set of verification instructions to 
determine if the set of subject instructions possess the 
property. If the set of subject instructions possess the 
5 property, then the verification processor 

cryptographically signs the set of instructions to produce 
signature information, and in one embodiment of the 
present invention, distributes the set of instructions 
with the signature information. In one embodiment, 

10 information pertaining to the property verified by the 
provider can be derived by a host from the set of subject 
instructions and the signature data. In another 

embodiment, the provider cryptographically signs property 
data identifying the property of the set of subject 

15 instructions verified by the provider. 

When a host receives the set of subject instructions 
and the signature, the host can use the signature to 
determine the integrity and the authenticity of the 
subject set of instructions, as well as the identity of 

20 the property verified by the provider. If the host cannot 
certify the set of subject instructions and the property 
data using the signature information, then the host does 
not execute the software. If the host can certify the set 
of subject instructions and the property data, then the 

25 host may execute the software. 

Brief Descrip tion of the Drawings 

FIG 1 shows a first embodiment of an apparatus in 
30 accordance with the present invention. 

FIG 2 shows a second embodiment of an apparatus in 
accordance with the present invention. 

FIG 3 shows a system- level embodiment of the present 
invention. 
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FIG 4 is a flow chart showing an embodiment of the 
verifier version management method in accordance with the 
present invention . 

FIG 5 is a flow chart showing an embodiment of the 
5 software certification method in accordance with the 
present invention. 

FIG 6 is a flow chart showing an embodiment of the 
signature checking method in accordance with the present 
invention. 

10 FIG 7 shows a system- level embodiment of the present 

invention where a plurality of certifiers certify a piece 
of software . 

FIG 8 is a flow chart showing an embodiment of the 
signature checking method of the present invention where 
15 a plurality of certifiers certify a piece of software. 

Polled Description 

One embodiment of an apparatus in accordance with the 
present invention is shown in FIG 1. A physically secure 

20 co-processor PSC) 101 is comprised of a processor 102; 
memory 103 storing certification instructions 108 adapted 
to be executed by the processor 102 to determine if a set 
of subject instructions has a particular property, and if 
it does, to sign the subject set with a private 

25 cryptographic key 104 also stored in memory 103; and an 
interface 105. The memory 103 and interface 105 are 
coupled to the processor 102.. A tamper-proof enclosure 
107 surrounds the processor 102 and computer readable 
memory 103. The interface 105 is disposed to convey 

30 electrical signals through the tamper-proof enclosure 107. 

In one embodiment of the present invention, the 
tamper-proof enclosure 107 includes a conductive strip 
bonded to the interior of the enclosure 107 which, when 
electrically interrupted (e.g., from an unauthorized 

35 attempt to open the enclosure 107) , erases the contents of 
the computer readable memory 103. In another embodiment, 
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the memory 103 stores instructions which the processor 102 
executes to analyze data received through the interface 
105. When this data conforms to predetermined conditions 
(e.g., ten consecutive invalid cryptographic keys are 
5 received by the secure co-processor 101 through the 
interface 105) , the processor erases the contents of the 
memory 103. 

In one embodiment of the present invention, the PSC 
is a smart card. In another embodiment, the PSC is circuit 
10 pack. In yet another embodiment, the PSC is a component 
on a modular hardware card. The PSC can be constructed in 
accordance with the disclosure of Secure Coprocessors in 
Electroni c Commerce Applications, by Bennet Yee and Doug 
Tygar, Proceedings of the First USENIX Workshop on 

15 Electronic Commerce, New York, New York, July 1995, which 
is incorporated herein by reference. 

The public and private cryptographic keys disclosed 
herein are meant to be used in a public key encryption 
system. In a public key encryption system, keys occur in 

20 corresponding pairs. One key of the pair is kept 
confidential (the "private key") , while the other key of 
the pair is shared (the "public key") . If one of the pair 
of keys is used to encrypt data, only the other of the 
pair can properly decrypt the data. 

25 In one embodiment of the present invention, data is 

signed by a certifier using* a public key encryption 
system. As used herein, the term "certifier" means a party 
that certifies software in accordance with the present 
invention. The certifier signs the data using the 

30 certifiers private key. The process of signing a piece of 
data produces a signature, which is a piece of information 
that can be sent to a host with the original data. The 
host can use the signature to ascertain if the data with 
which the signature is associated has been certified by a 

35 particular party or member of a group of parties. 
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In one embodiment, a signature is produced by 
generating a message digest from the data and then 
encrypting the message digest using the certifiers 
private key. A message digest functions much like a 
5 serial number to uniquely identify the data from which it 
is derived. Here, the encrypted message digest is the 
signature . 

The original data and its encrypted message digest 
are sent to a host. The host uses the same method used by 
10 the certifier to derive the same message digest from the 
data. The host then uses the certifiers public key to 
decrypt the encrypted message digest (the signature). 
Only the certifiers public key can decrypt the signature 
properly. If the decrypted signature from the certifier is 
15 identical to the message digest generated by the host, 
then the signature has been determined to be valid by the 
host, and the host is assured that the data was certified 
by the certifier. If the decrypted signature is not the 
same as the message digest generated by the host, then the 
20 signature is determined to be invalid by the host. 

Another embodiment of the present invention is shown 
in FIG 2. Application Specific Integrated Circuit (ASIC) 
201 embodies certification instructions 202 adapted to be 
executed by the ASIC 201 to determine if a subject set has 
25 a particular property, and if it does, to sign it with a 
a private cryptographic key stored in memory 203 . In one 
embodiment, memory 203 is random access memory (RAM) . In 
another embodiment, memory 203 is a hard disk drive. A 
tamper-proof enclosure 205 surrounds ASIC 201 and memory 
30 203. Interface 206 is disposed to provide an electrical 
connection through the tamper-proof enclosure 205. 
Interface 206 and memory 203 are coupled to ASIC 201. 

In another embodiment of the present invention, the 
processor 102 shown in FIG 1 is not surrounded by a 
35 tamper-proof enclosure 107, the processor being 
sufficiently trusted (e.g., because it operates in a 
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secure environment, etc.) not to require such an enclosure 
107. 

FIG 3 shows a system-level embodiment of the present 
invention. Administrator 401, software provider 402, and 
5 hosts A 404, B 405 and C 406 are coupled to network 407. 
In this embodiment, software certification is performed by 
PSC 403 coupled to provider 402. In another embodiment, 
certification is performed by the provider 402 itself. 

PSC 403 analyzes a subject set to determine if it 
10 possesses a particular property, and if it does, it signs 
the subject set. In one embodiment of the present 
invention, PSC 403 uses resources (e.g., memory, processor 
time, etc.) at the provider 402 to analyze and sign (i.e., 
to certify) the subject set. 
15 in one embodiment, administrator 401 sends a new 

authorization message that includes updated certification 
instructions and private cryptographic keys to the PSC 
403. In one embodiment, administrator 401 also sends an 
invalidation message that includes public key invalidation 
20 information, and sends new authentication information that 
includes a public cryptographic key to hosts A 404, B 405 
and C 406. In other embodiments, an invalidation message 
is sent that serves to notify the host that the present 
version of the certification instructions is invalid. In 
25 one embodiment, this results in the invalidation of a 
symmetric key stored at the host. 

In one embodiment of the present invention, if the 
subject set has a particular property, then the PSC 403 
uses the private key from the administrator 401 to 
30 generate a signature and produce a certificate. A 
certificate includes, but need not be limited to, the 
signature. In one embodiment of the present invention, the 
certificate also includes signed information about the 
particular property that the subject set is determined to 
35 possess by the PSC 403. In another embodiment, the 
identity of the property is determined by the way in which 
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signature is produced . For example, in one embodiment, 
the identity of the property is determined by the identity 
of the group of keys to which the key used to sign the 
subject set belongs. 
5 In one embodiment, the subject set of instructions is 

sent to a host 404. A host 404 can use the public key 
received from the administrator 401 to check the signature 
in the certificate associated with a subject set of 
instructions. If the signature is determined to be valid, 

10 then the host 404 is assured that the subject set has the 
property indicated by the certificate. If the signature is 
determined not to be valid, then no such assurance is 
provided to the host 404. 

In another embodiment of the present invention, 

15 public and private keys are managed by the provider 402. 
In one embodiment, the keys are managed using certificates 
embedded in the client, or else are pushed to the client 
using "push" technologies. Push technologies allow a first 
party to send information to a second party, whereas "pull" 

2 0 technologies only permit the second party to receive 
information from the first party at the second partys 
request. Also, key revocations can be pushed to the client 
or pulled from a central repository (such as the 
administrator 401) when the client starts. 

25 FIG 4 shows a flow chart that illustrates an 

embodiment of verifier version management method in 
accordance with the present invention. 

The administrator determines if the presently- 
distributed version of the certification instructions is 

30 outdated, step 301. If the present version outdated, then 
the administrator sends an invalidation message to a host, 
step 302. In one embodiment, the invalidation message 
indicates to a host that the presently distributed public 
key N is now invalid. In another embodiment, the 

35 invalidation message indicates that a symmetric key is 
invalid. In the general case, the invalidation message 
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carries information to the host that indicates that the a-, 
given version of the certification instructions is now 
invalid or outdated. The present invention is meant to 
include any invalidation message that functions as such. 
5 Thereafter, hosts will determine that signatures from 
certifiers who have used the outdated version of the 
certification instructions are invalid. 

The administrator then sends a new authorization 
message to the certifier, step 303. An authorization 
10 message causes the certifier to use a new or updated 
version of certification instructions, and also provides 
information on how to generate a certificate signifying 
that the new certification instructions have been used to 
determine if a subject set possesses a particular 
15 property. In one embodiment, the authorization message 
includes a new version of the certification instructions 
and a new private key. 

New authentication information is also sent to the 
host, step 304. Authentication information is used by the 
20 host to authenticate a certificate, i.e., determine if a 
certificate is valid. In one embodiment of the present 
invention, this new authentication information includes a 
new public key to replace a public key invalidated by the 
invalidation message. In another embodiment, the 
25 authorization message includes a new symmetric key and a 
segment of update instructions* adapted to be patched into 
the present version of the certification instructions. 

FIG 5 is a flow chart showing an embodiment of the 
certification method in accordance with the present 
30 invention. In one embodiment, the certification process is 
performed by a PSC in conjunction with a provider. In 
another embodiment, the certification process is performed 
by the provider alone. In another embodiment, the 
certification is performed by a third party that is 
35 neither a provider nor a host. In yet another embodiment, 



WO 98/34365 



PCT/US98/01215 



15 

the certification process is performed by a plurality of 
certifiers . 

A certifier receives a piece of software from a 
manufacturer or distributor, step 341. The provider uses 
5 a version of the certification instructions to determine 
if the subject set possesses a particular property, step 
342. If the subject set possesses the property, the 
provider signs the subject set to produce a certificate 
with a signature, step 343. In one embodiment of the 
10 present invention, the provider also signs a statement 
that describes the particular property of the subject set. 
In one embodiment, the certificate is produced using 
private cryptographic key N associated with version N of 
the certification instructions. 
15 The provider distributes the software with the 

certificate, step 344. In one embodiment, the provider 
distributes the software and certificate by sending them 
to a host. In another embodiment, the provider distributes 
the software and certificate by sending them to an 
20 intermediary. In one embodiment, the subject set is in 
binary form. In another embodiment, the subject set is in 
source ^code form. 

FIG 6 is a flow chart showing an embodiment of the 
signature checking method in accordance with the present 
25 invention. The host receives the subject set (the 
software) and the certificate from a provider, step 351. 
The host determines if the certificate is valid, step 352. 
If the certificate is valid, then the host is assured that 
the subject set possesses the property, and can execute 
30 the subject set, step 353. If the certificate is not 
valid, then the host is not so assured, and does not 
execute the subject set. In one embodiment, if the host 
determines that the certificate is not valid, the host 
sends a message to the administrator indicating that the 
35 host was unable to verify a signature, step 354. 
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FIG 7 shows another system- level embodiment of the 
present invention that includes a plurality of certifiers. 
Certifiers A 701 , B 702 and C 703 each certify a subject 
set of software and each generates a certificate. The 
5 subject set is sent to the host 705 by a provider 704 
through the network 706. The certificates generated by 
the certifiers 701, 702 and 703 are sent to the host 704 
for verification. 

FIG 8 is a flow chart showing an embodiment of the 
10 the signature checking method of the present invention 
where a first plurality of certifiers are adapted to 
certify a piece of software. The. host receives a copy of 
the subject set (the software) from the provider, step 

801. The host then receives a certificate for the subject 
15 set from each of a second plurality of certifiers, step 

802. The second plurality can be equal to, or less than, 
the first plurality. The host determines if each 
certificate is valid, step 803. If the number of 
certificates determined to be valid is at least equal to 

20 a threshold, then the host can execute the subject set, 
step 804. If the number of certificates determined to be 
valid is less than the threshold, then the host does not 
execute the subject set, step 8 05. In one embodiment, the 
threshold is predetermined. In another embodiment, the 

25 threshold is determined on- the -fly by the host to fit the 
particular circumstances surrounding a given subject set. 
For example, for a subject set obtained from a provider 
not well known or trusted by the host, the threshold can 
be set to be larger. For a subject set from a more 

30 trusted provider, the threshold can be set to be lower. 

The present invention advantageously provides a 
substantial performance advantage over the known systems 
that verify software at the host prior to each execution. 
The advantages of the present invention are achieved in 

35 part by providing the host with assurance that a piece of 
software can be trusted to have a particular property by 
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requiring the host only to check a signature at execution 
time, while the substantially more burdensome task of 
certifying the software is carried out more centrally by 
the provider. This advantageously reduces the need to 
5 extensively distribute and exhaustively maintain current 
software certifiers to a large number of distributed 
platforms, as is required by systems where the 
verification of software is performed by the host at run 
time . 

10 In an embodiment of the present invention where the 

set of subject instructions is sent in binary form from 
the provider to the host, the present invention also 
advantageously provides software property assurance to the 
host without requiring the manufacturer to disclose 

15 valuable confidential intellectual property, such as 
source code or invariants. 

In another embodiment of the present invention, 
certification instructions stored in a PSC comprise a 
proof checker. A manufacturer generates a proof carrying 

20 binary version of its software (e.g., in annotations of 
the binary) , and reveals the annotations and the proof to 
the PSC. The PSC generates the certification condition 
from the binary, checks the proof, and signs the binary 
together with a statement to the effect that the relevant 

25 security property is established to obtain a certificate. 
This advantageously provides assurance to the client that 
the code has the security property without revealing to 
the client the proof or . the annotations, thus 
advantageously protecting valuable intellectual property 

30 of the manufacturer. The logistical advantages of the 
present invention pertaining to certifier version control 
and key management also apply in this embodiment. 
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WHAT IS CLAIMED IS : 

11. A method for providing assurance to a host that a set 

2 of subject instructions possesses a particular property, 

3 comprising the steps of: 



4 a. determining if the set of subject instructions 

5 possesses the particular property at a 

6 certifier; 

7 b. if the subject set of instructions is determined 

8 to possess the particular property, then: 

9 i. signing the set of subject instructions at 

10 the certifier to obtain a signature; 

11 ii. distributing the set of subject 

12 instructions and a certificate that 

13 includes the signature to the host. 



1 2. The method of claim 1, wherein the set of subject 

2 instructions are signed using a private cryptographic key 

3 at the certifier. 

1 3. The method of claim 1, wherein the set of subject 

2 instructions are signed using a symmetric cryptographic 

3 key at the certifier. 

1 4. The method of claim 1, wherein the set of subject 

2 instructions are distributed to the host from a provider. 

1 5. The method of claim 1, wherein the set of subject 

2 instruction© are distributed to the host from the 

3 certifier. 

1 6. The method of claim 1, wherein the set of subject 

2 instructions and the certificate that includes the 

3 signature are received together at the host. 
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1 7. The method of claim 1, further comprising the steps 

2 of signing a statement that contains information 

3 pertaining to the particular property possessed by the 

4 subject set and including said signed statement in the 

5 certificate. 

1 8. The method of claim 1, further comprising the steps 

2 of : 



3 c. determining if the present version of 

4 certification instructions used by a certifier 

5 to determine if a subject set of instructions 

6 possesses a particular property is outdated; 

7 d. if the present version of the certification 

8 instructions are determined to be invalid, then 

9 sending a invalidation message to a host. 



1 9. The method of claim 8, wherein the invalidation 

2 message indicates that a public key is invalid. 

1 10. The method of claim 8, further comprising the step of 

2 sending a new authorization message to a host. 

1 11. The method of claim 10, wherein the new authorization 

2 message includes a new public key. 

1 12. The method of claim 10, wherein the new authorization 



2 message includes new certification instructions and 

3 information on how to generate a certificate 

4 signifying that the new certification instructions 

5 have been used to determine that a subject set has a 

6 particular property. 



1 13. The method of claim 1, wherein the particular 

2 property is the identity of the certifier of the set of 

3 subject instructions. 
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1 14. The method of claim 1, wherein the particular 

2 property is the identity of a compiler used to generate 

3 the binary version of the subject set of instructions. 

1 15. The method of claim 1, wherein the particular 

2 property is the identity of the manufacturer of the 

3 subject set of instructions. 

1 16. The method of claim 1, wherein the particular 

2 property is the version of the certification instructions 

3 used to analyze the subject set of instructions. 

1 17. The method of claim 1, further comprising the step of 

2 determining at the host if the signature received in the 

3 certificate is valid. 

1 18. The method of claim 17, wherein if it is determined 

2 at the host that the signature is not valid; then sending 

3 an invalid signature message to the provider of the 

4 subject set. 

1 19. The method of claim 1, wherein a first plurality of 

2 certifiers determine if the set of subject instructions 

3 possesses a particular property, and wherein a second 

4 plurality of certifiers each send a certificate including 

5 a signature to the host, and further comprising the steps 

6 of: 



7 c. receiving the subject set of instructions at the 

8 host ; 

9 d. determining at the host if a threshold number of 

10 signatures is valid; 

11 e. if the threshold number of signatures are valid, 

12 then determining at the host that the subject 

13 set of instructions possesses the particular 

14 property. 
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1 20. A certifier comprising: 



2 a. a processor; 

3 b. a memory that stores a set of certification 

4 instructions adapted to be executed on said 

5 processor to determine if a set of subject 

6 instructions possesses a particular property, 

7 and if it does, then to sign the subject set of 

8 instructions to obtain a signature; 

9 c. a port adapted to be connected to a network; 
10 said port and memory coupled to said processor. 



1 21. The certifier of claim 20, further comprising a 

2 tamper-proof enclosure surrounding said processor and 

3 memory, and wherein said port comprises an electrical 

4 interface disposed to conduct electrical signals through 

5 said tamper-proof enclosure. 

1 22. A medium that stores instructions adapted to be 

2 executed by a processor to perform the steps of: 



3 a. determining if a set of subject instructions 

4 possesses a particular property; 

5 b. if the subject set of instructions is determined 

6 to possess the particular property, then: 

7 i. signing the set of subject instructions to 

8 obtain a signature; 

9 ii. distributing 'the set of subject 

10 instructions and a certificate that 

11 includes the signature. 
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